(how to improve SOFT-ICE)
by The Owl (Winice wizard eccelso)
NO MORE annoying anti SOFT-ICE tricks or
how to improve SOFT-ICE!
intro
today's best EXE protectors contain code to prevent debugging with
SOFT-ICE, which is the best debugger among the ones i came across so
far. following protectors are known to me to defeat SOFT-ICE:
EEXE (Encrypt Exe found in FZC.EXE)
HACKSTOP (found in WWPACK.EXE)
PROTECT! (found in various files)
GUARDIAN ANGEL (found in some versions of HWINFO.EXE)
EXELITE (a Polish exe compressor)
the one written by PREDATOR 666 (found in DCA.EXE v1.4)
the one used by Martin Mal�k (found in HWINFO.EXE v3.05 and up)
DS-CRP by Dark Stalker (hi!)
SECURE v0.19 by the authors of WWPACK
ALEC v1.5 (the very best protector :-) by Random
and a few others i don't remember right now...
the problems
SOFT-ICE can be detected/halted/crashed in many ways, here's a short
list of them (some of them only makes single stepping harder but not
impossible). i also included a short note on the effects for each version
of SOFT-ICE:
:-( this trick works,
:-) it causes no problems
1. by the use of the INT3 interface provided by SOFT-ICE one can
check for the presence of SOFT-ICE and then have it execute various
commands, e.g. HBOOT (see HackStop). the loader part of SOFT-ICE
also leaves some traces in the low DOS memory, so one can find out
the entrance values of the INT3 interface even if they were changed
(see HMVS - a heuristic macro virus scanner - by J. Valky and
L. Vrtik that uses SECURE v0.19). the Windows versions can also be
detected by the following code (thanks to Dark Stalker and ACP :-):
mov ebp,"BCHK"
mov ax,4
int 3
cmp ax,4
jne winice_installed
it seems that BoundsChecker talks to SOFT-ICE via an interface very
similar to the one between LDR.EXE and SOFT-ICE (although it's
completely undocumented, as far as i know...)
DOS: :-(
W31: :-( (but the SECURE method is :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
2. by checking for various devices SOFT-ICE installs ("CVDEBUG",
"NU-MEGA", "SOFTICE1") and searching the part of the code SOFT-ICE
leaves in the low DOS memory for some patterns (e.g. "CVDEBUG",
"NU-MEGA", "SEGMAP", "S-ICE" (the latter coming from the filename),
and any instruction sequence that's left there) one can detect the
presence of SOFT-ICE. the Window$ versions provide a VXD entry point
that can be get by:
mov ax,01684h
mov bx,0202h ; VXD ID for Winice, check out Ralf Brown's INTLIST
xor di,di
mov es,di
int 2fh
mov ax,es
add di,ax
cmp di,0
jne winice_is_installed
the Window$ versions can also be detected by calling the "debugger
install check" function of the Window$ debug kernel (int 42/ax=0041),
for more details see Ralf Brown's INTLIST.
see HWINFO.EXE and DS-CRP.COM for an extensive application of these
checks...
DOS: :-(
W31: :-) but the VXD entry point check is :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
3. by the use of the undocumented ICEBP/INT01 instruction (opcode 0xF1):
SOFT-ICE gives a short beep before the execution of this instruction
(it will be reflected back to the V86 mode handler, thus at least
the intended handler will get it) which can be VERY annoying (and
make the execution VERY slow), see EEXE for an application of this.
DOS: :-(
W31: :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
4. by using the TRAP flag, one can use the single stepping feature to
call a protection routine (e.g. a decryptor). the problem is, that
during single stepping SOFT-ICE clears the TRAP flag for the V86 task
and will neither execute nor step into the INT01 handler of the
V86 task. many schemes use this trick.
DOS: :-(
W31: :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
5. by the use of the debug (DRx) and control (CRx) registers:
accessing these registers in V86 mode leads to a General Protection
Fault (INT0D), which SOFT-ICE doesn't handle correctly (it's normally
used for emulating instructions that access the interrupt flag, the
debug registers, the control registers, etc.). the protected mode
handler emulates instructions that access these registers by
executing them, however it doesn't make note about this for itself,
i.e. whenever a debug fault is triggered SOFT-ICE will think that
it must pop up and won't reflect back this exception to the V86 mode
handler (that's waiting for it in vain). for a working example see
GUARDIAN ANGEL. furthermore, accessing DR4/5 and CR1 will halt
SOFT-ICE with a General Protection Violation error message, which is
of course quite disturbing if it's used many times in the program...
and best of all by accessing CR4 SOFT-ICE simply crashes since
there's no emulation code for this kind of instructions (there's a
jump table that tells SOFT-ICE which routine to use to handle these
instructions and the table ends with CR3...). this method was first
used by Random in his ALEC.EXE v1.4 :-)
another sad fact is that the emulation in SOFT-ICE is not complete:
it ALWAYS uses eax no matter what the original instruction was...
e.g. mov dr0,ebx will load dr0 from eax!
mov ecx,dr0 will load eax from dr0!
i guess it's needless to say how easy it is to detect this behavior...
a sidenote for protection writers: other memory managers that run
DOS in V86 mode may or may not handle these instructions correctly,
so the use of this trick is highly discouraged.
DOS: :-(
W31: :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
6. by the use of INT08, which is the timer interrupt in real mode DOS,
and the Double Fault Exception in protected mode. the protected mode
handler checks whether it was entered from V86 mode or not, and in
the first case it reflects back this interrupt to the V86 mode
handler. however, one can't single step into it.
DOS: :-(
W31: :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
7. by the use of the INT07 interrupt (this is the Coprocessor Not
Available Exception):
instead of reflecting back this interrupt to the V86 mode handler,
SOFT-ICE tries to skip the offending coprocessor instruction (it
checks for some opcodes). it seems the Nu-Mega folks never thought
it would be called directly... for a real life application get some
programs written (and protected) by Predator 666.
DOS: :-(
W31: :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
8. by the use of the Invalid Opcode Exception (INT06):
SOFT-ICE tries to emulate some instructions (e.g. LOADALL), and then
reflects back this exception to the V86 mode handler. however,
certain opcodes aren't recognized and will give you an error message
(i.e. execution will be interrupted, if the protection scheme uses
this trick).
DOS: :-(
W31: :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
9. by using direct INTxx calls that are triggered by hardware
interrupts (e.g. INT08-INT0F, INT70-INT77, if the vectors in the PIC
are not reprogrammed), one will not be able to single step into the
interrupt handler. in fact, SOFT-ICE will even execute the next
instruction and just then stop (if the next instruction is also an
INTxx call of this type then it will be stepped over as well, and so
on). so far, i know of no protection scheme that uses this trick,
but i guess i've just given out a good idea :-).
DOS: :-(
W31: :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
A. by reloading IDTR one can change the base and size of the interrupt
table in real mode as well. however, SOFT-ICE will not emulate this
instruction (it causes a General Protection Fault in V86 mode) thus
a protection using LIDT won't run. the only problem is that memory
managers don't like it very much, so probably we won't see it in a
real life protection scheme, but one never knows :-).
DOS: :-(
W31: :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
B. sometimes one has to call an interrupt directly (GENINT xx), e.g. to
dump a memory range to disk by using one's memory resident dumper
(you know what i mean :-) and it's very annoying that SOFT-ICE
doesn't stop after the interrupt call but executes the program
being debugged (thus one has to set a breakpoint for a moment at the
current CS:IP which will result in an unwanted 0xCC byte in the dump,
if all debug registers are already used).
DOS: :-(
W31: :-(
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
C. in plain DOS INT3 and INT1 are handled by the same routine (which is
a simple IRET). however, SOFT-ICE changes the INT3 handler of the
V86 task to another IRET which can be detected by comparing its
offset to the one of the INT1 handler. see HWINFO.EXE for
an application
DOS: :-(
W31: :-)
W95: not tested yet (probably same as W31)
WNT: not tested yet (probably same as W31)
the solutions
in the following part you'll be presented with some ideas about the
solution for the problems described above (the file offsets refer to the
DOS version v2.80, but the ideas should work for other versions, as well.
the easiest way to apply the patches is using Hacker's View which can
be found in HIEW531.ZIP).
one general problem is that SOFT-ICE (at least the DOS version) doesn't
reprogram the hardware interrupt vectors, and this makes life (and the
interrupt handlers) a bit more complex. the IDT that SOFT-ICE uses has
entries that point to the following type of code:
push xx
jmp handler_xx
where xx goes from 0x00 to 0xFF. in v2.80 this code begins at offset
0x4534. the Win31 version has a very similar code beginning at offset
0x14167 in v1.52:
push d,[offset_xx]
jmp handler_xx
if you want to understand the patches that follow right below, you
should study the interrupt handlers (and you should also have a good
understanding of protected mode). however, some problems cannot be solved
without understanding the internal flags of SOFT-ICE, and this requires a
complete disassembly of it, which is a quite hard task i can tell.
anyway, sooner or later it will be done, and then we'll have the
ultimate debugging/cracking tool in our hands 'cos we'll be able to put in
some missing functions, e.g. emulation of FlatRealMode, tracing INT1, PIC
reprogramming, prefetch queue emulation, dumping a memory range to disk,
etc. until then, enjoy the poor man's patches...
1. some exe protections mentioned earlier are based upon the INT3
interface of SOFT-ICE (see Ralf Brown's Interrupt List for details).
this interface is activated when the protected mode INT3 handler of
SOFT-ICE encounters the magic values in SI and DI. that is, when you
try to trace through an INT3 call, SOFT-ICE will regain control,
check for the magic values, and in case they are not found, it will
reflect back this interrupt to the V86 mode INT3 handler (which it
was supposed to do anyway). if it finds the magic values, then
it'll execute the command given in AX (and DS:DX). all of these
checks happen invisibly to the hacker, so there seems to be no
solution to defeat this kind of protection (well, there's a slow way
if you step through every instruction and before the "guilty" INT3
call you change one or two registers).
however, there's a simple solution: change the magic values SOFT-ICE
is looking for and this will defeat those protectors based upon the
INT3 interface. however, it's easier said than done because both
SOFT-ICE (and WIN-ICE) itself and (W)LDR.EXE use this interface for
some kind of intra/inter process communication. so every reference
to the magic values will have to be changed!
to keep the story short here's what i've come up with:
browsing a few minutes in Hacker's View (another important tool ;-)
i found the places where those changes had to be done. in order to
avoid changes where those magic values occur by chance, i wrote an
MSUB script to change whole instructions (they represent enough
context). the amount of necessary changes would have forced me to
use some search&replace utility, anyway. MSUB.EXE can be found in
MSUB13.ZIP (use an ftp search engine to find it).
the scripts
SICE-VAL.MS: you should specify the old and new magic values in it
(note that numbers are decimal!)
SICE2NEW.MS: it will replace the old magic values with the new ones.
there are almost 2^32 possible values, only that value
is forbidden for SI that equals to the version of
SOFT-ICE (for v2.80 it is \128\2, i.e. 0x0280). before
SOFT-ICE installs itself, it checks for its presence by
using an undocumented function of its INT3 interface by
setting AH to 0 or 1. on return SI will be loaded with
the version number or left unmodified if it's not
installed yet, that's why the version number must differ
from the preloaded value of SI.
example usage
MSUB.EXE SICE2NEW.MS S-ICE.EXE LDR.EXE
if you're fed up with the shareware delay built into MSUB.EXE,
here's how you can get rid of it (thanks to a friend of mine ;-)
patch MSUB.EXE v1.3 (113,152 bytes long) as follows:
offset old new
00002307: ?? EB
00002308: ?? 03
0000C0DF: 77 EB
the protection that SECURE uses is quite clever 'cos it checks the
first 16 kBytes for the instruction sequence of
mov si,SI_MAGIC
mov di,DI_MAGIC
they're encoded as 0BEh,x,y,0BFh,u,v where x,y,u and v are the magic
values. when it finds 0BEh and 0BFh separated by two bytes from each
other then it calls INT3 with the supposed magic values (the INT3
handler is a simple IRET, so no problem should arise if SOFT-ICE is
not installed). and guess what happens when SECURE finds the traces
of the loader part of SOFT-ICE in that low memory area...
the only solution that would defeat this kind of protection is to
change the instructions that load SI and DI before the INT3 calls
(unfortunately you can't avoid those calls since SOFT-ICE has to
check for its presence and do other things). for obvious reasons
(i guess one of the previous versions of this file gave the SECURE
authors the idea...) i won't give you tips on how to do it, i hope
you're smart enough to do it yourselves.
the only limit is that you have 6 bytes of space to load both SI and
DI (i checked that whenever SOFT-ICE uses the INT3 interface it loads
SI and DI by two consecutive instructions, i.e. you can use the MSUB
scripts to search for and replace them). another method could be to
change the HBOOT command to something else (by MSUB of course),
however other dangerous commands could be still issued...
the BoundsChecker interface can be modified in the same way we did
it with the rest of the INT3 interface: simply modify the value that
is expected in ebp (but BoundsChecker must be changed as well!).
look for the string "KHCB" to find the appropriate place.
the following file offsets are valid for WINICE for Win 3.1 v1.52:
offset old new
000130C7: 'K' ?
000130C8: 'H' ?
000130C9: 'C' ?
000130CA: 'B' ?
for WINICE for Win95 v3.0:
offset old new
00016FDD: 'K' ?
00016FDE: 'H' ?
00016FDF: 'C' ?
00016FE0: 'B' ?
and for WINICE for Win95 v3.01:
offset old new
000243F0: 'K' ?
000243F1: 'H' ?
000243F2: 'C' ?
000243F3: 'B' ?
2. the device names can be changed to anything you want, look at the
beginning of S-ICE.EXE. the real problem is when the protection
checks for instruction sequences. my only advice is that step through
the protection and see which part of the code is checked for, then
try to modify it in S-ICE.EXE (or disassemble, modify and then
recompile the whole executable, but that's not gonna happen for
a long time, i guess... :-).
to defeat the int41 check, you have to change both the return value
of the real and protected mode handlers in WINICE and the value that
is checked for in KRNL386.EXE, VMM32.VXD, EMM386.EXE, IFSHLP.SYS and
NET.EXE. all these changes are necessary otherwise some WINICE
commands (HWND, TASK) won't work 'cos apparently they rely on some
Window$ functions which are available only in the debug kernel (and
during startup these programs/drivers do this int41 check which will
fail if you don't change the values they're expecting, as well).
there're five places in WINICE that have to be patched (one is a cmp,
the other four are mov's) and one in each one of the rest. sorry,
that i don't provide you with detailed offsets, but there're too many
versions/combinations of both WINICE and Win31/Win95... note, that
after these changes other programs that want to use debug kernel
functions will fail :-)
and now let's talk about the VXD entry point check. the ID is stored
at file offset 0x7821E in WINICE for Win95 v3.01 (to find it in
other versions as well just look for "SICE ", and the ID will be
a few bytes before this text).
so to change the ID just overwrite it there. however, it's not
enough since some companion programs also test for WINICE by trying
to get the VXD entry point, i.e. they have to be modified as well.
they're DLOG.EXE and WLDR.EXE, and search for int2F (opcode: 0xCD
0x2F) to get to the right place... :-)
anyway, for the versions that come with WINICE for Win95 v3.0,
the file offsets of the ID are 0x625/6 and 0x68B9/A respectively.
3. what we have to do is simply skip the unnecessary parts in the
handler (the beeps) and simulate the instruction as it would have
been a direct INT 01 call (opcode: 0xCD 0x01). this way one will not
only get rid of the beeps but be able to trace into the handler as
well (and we'll have some space to put some extra code in when we'll
need it :-).
offset old new
00001DD5: 50 EB
00001DD6: 51 60
4. [this part is being worked on]
5. there are two possible solutions: we either disable the DRx emulation
feature of SOFT-ICE (this is quite easy to do) or correct it (this is
really hard to do). SOFT-ICE emulates each instruction by executing
a function whose offset is looked up in a table. each function ends
in the same way: IP of the V86 task is incremented by the appropriate
amount of bytes. so to disable emulation we'll change the pointers
in that table to the common end of the functions, this way these
instructions will essentially be handled as NOPs. i don't know
whether it's worth to do it or not, since this modification can be
detected by simply loading one of the debug registers and then
checking whether it's really been modified or not. a more elegant
solution would be to reserve a few bytes in the data segment of
SOFT-ICE for storing the values of these registers and emulate the
instructions (or at least their loading). anyone out there willing
to do that?
anyway, here's how to do the patch: the table itself is at file
offset 0x1F1DD and it has 12 words in it pointing to the
emulation code of the following instructions:
mov eax,dr0 and mov dr0,eax
mov eax,dr1 and mov dr1,eax
mov eax,dr2 and mov dr2,eax
mov eax,dr3 and mov dr3,eax
mov eax,dr4 and mov dr4,eax
mov eax,dr5 and mov dr5,eax
mov eax,dr6 and mov dr6,eax
mov eax,dr7 and mov dr7,eax
mov eax,cr0 and mov cr0,eax
mov eax,cr1 and mov cr1,eax
mov eax,cr2 and mov cr2,eax
mov eax,cr3 and mov cr3,eax
note that there's no offset for emulating CR4...
the offset of the common exit point (i.e. the new value you may want
to set these pointers to) is 0x175A (this is NOT a file offset...).
these patches still don't cure the problem with CR4. if you decided
to get rid of the emulation entirely (including CR4) then you can
do it much easier:
offset old new
00002E7E: 03 0A
00002E7F: 00 01
6. i'll give you a general solution in section 8 since INT08 is just a
a subset of the hardware interrupts which are discussed there.
7. this problem can be solved quite easily: we replace the original
protected mode handler with the one that serves all not_IRQ_related
interrupts (and whose only task is to reflect them back to the
V86 mode handler).
offset old new
0000455A: B6 14
0000455B: DF D6
8. what we have to do is to skip the call that prints the error message
and simply reflect this interrupt back to the V86 mode handler.
note that your buggy programs won't cause SOFT-ICE to pop up after
this patch :-) (however, you'll be able to break in and see what
went wrong).
offset old new
00002447: A9 C3
9. now we'll make use of the extra space we made in the original INT01
handler. we have to check whether the interrupt was triggered by a
hardware IRQ or not. this can be done by the following routine:
push eax ; save the registers that will be modified
pushf ; the order of PUSHs is important!
mov al,0Bh ; we'll read in the in-service registers
out 20h,al ; master PIC
out 0A0h,al ; slave PIC
; there might be needed a short delay here
; however, on my machine it isn't :-)
in al,20h ; read INTs being serviced by master PIC
mov ah,al ; save for later test
in al,0A0h ; read INTs being serviced by slave PIC
test ax,0FFFFh ; was it a hardware int?
jnz original ;
popf ; restore flags
pop eax ; the general handler doesn't expect it
jmp offset 1B70h ; this has to be the general handler (this offset
; is valid in v2.80)
original:
mov ax,8 ; the first two instructions of the original handler
popf ; were push eax, mov ax,8, thus we won't pop eax
jmp offset 1A77h ; this has to be the original handler's offset
; plus 5 bytes (the length of push eax, mov ax,8)
and at the beginning of the original handler (offset 0x1A72) we put:
jmp offset 1DD7h ; and since it's only 3 bytes long,
; we get 2 spare bytes :-)
the binary patches follow:
offset old new
00001A72: 66 E9
00001A73: 50 62
00001A74: B8 03
00001DD5: 50 EB
00001DD6: 51 60
00001DD7: B9 66
00001DD8: 03 50
00001DD9: 00 9C
00001DDA: B0 B0
00001DDB: 03 0B
00001DDC: E6 E6
00001DDD: 61 20
00001DDE: 51 E6
00001DDF: 33 A0
00001DE0: C9 E4
00001DE1: E2 20
00001DE2: FE 8A
00001DE3: E2 E0
00001DE4: FE E4
00001DE5: E2 A0
00001DE6: FE A9
00001DE7: E2 FF
00001DE8: FE FF
00001DE9: E2 B8
00001DEA: FE 08
00001DEB: E2 00
00001DEC: FE 75
00001DED: E2 06
00001DEE: FE 9D
00001DEF: E2 66
00001DF0: FE 58
00001DF1: E2 E9
00001DF2: FE 7C
00001DF3: E2 FD
00001DF4: FE 9D
00001DF5: E2 E9
00001DF6: FE 7F
00001DF7: E2 FC
A. to solve this problem we should do a complete disassembly of SOFT-ICE
since we have to keep track of the base and size of the V86 mode
interrupt table, and this requires too many changes to be worth to do
it with simple byte patches.
B. a somewhat lame (but it's more than nothing) solution is the
following: we chain in a P RET command after GENINT by patching
the jump at the end of the GENINT handler to the beginning of P RET.
after executing GENINT we'll land at the IRET of our handler and
a further P or T will take us back to the original instruction we
were at. i said it was somewhat lame... but it works :-)
offset old new
000118BF: BC 00
000118C0: E0 C7
C. before executing anything call up SOFT-ICE and change the offset of
the V86 mode INT3 handler to the one of the INT1 handler.
D. !!! SURPRISE !!!
while you're in WINICE for Win95 v3.0 or 3.01 type in the following
command: "ver ice" and see what you get... however, note that due
to a bug (or feature?) you can use only once this command during
a session, you have to restart WINICE to be able to get the
message again.
and while we're at undocumented features, try out "ver ?" as well.
in the next release, i'll try to write a detailed description
of the new commands (not that if it were that hard to find out...)
unsolved mysteries :-)
1. even the Nu-Mega docs tell about a problem when SOFT-ICE for DOS is
loaded from the command line: if HIMEM.SYS is installed the machine
simply reboots. i tracked down the problem and found out that the
processor resets itself because of a triple fault. it happens so:
after preparing the IDT and GDT (and loading IDTR and GDTR), paging
will be enabled in CR0, and then DS and ES will be loaded a
descriptor offset of 8. however, both this descriptor and the IDT
seem to be invalid, and this leads to a triple fault. unfortunately,
i couldn't find out what goes wrong during the setup of IDT and GDT,
perhaps someone else out there will do the dirty job :-)... and maybe
Nu-Mega will award you with a free, legal version :-)).
2. on a Cyrix 486DLC-40 system (both with and without a coproc) SOFT-ICE
gets a Page Fault and halts if the processor is running at 40 MHz,
but works fine at 33 MHz. the Page Fault seems to happen while the
code window is being put out (i.e. during the execution of the wc
command). this is nonsense! so far, no solution... and yes, it's
another dirty job...
P.S. for everyone
perhaps there's someone out there who didn't know it so far...
WINICE can be used without Window$ (and you'll be able to debug
programs that use some DOS extender, if it can make use of DPMI, but
that's the case with the most popular ones, e.g. DOS4GW or PMODE/W)!
the trick is that you have to make a 'crippled' version of Window$,
i.e. make Window$ start without its GUI. a complete description of
this can be found at the following URL:
http://www.fys.ruu.nl/~faber/Windows_No_GUI
after creating this GUI-less Window$ all you have to do is to start
WINICE (beware, your normal Window$ shouldn't be on your PATH!) and
voila, you'll be in a DOS session (i hope that you could find it out
yourself that you had to start COMMAND.COM as your KRNL386.EXE...)
with WINICE being able to pop up whenever you need it (of course, for
native Window$ programs you'll need a full Window$).
and if we're at Window$ here's another trick: if you don't want to
see the logo being shown every time you start Window$, either start
WIN.COM with a command line paramater of ':' i.e.
WIN.COM :
or (as the above method doesn't work with our GUIless version since
WINICE doesn't seem to pass any parameters or you are too lazy to
type in every time 2 more characters :-) look for the string 'LOGO'
in WIN.COM and change it to something else (it's enough to change
only one bit). note, that the WIN.COM of Window$ for Workgroups
doesn't like this patch...
P.S. for protection writers
i know that some of the above modifications can be defeated (i could
do it myself) however i won't make your life easier... i hope you
understand why :-)
The Owl 1997
SICE-VAL.MS cut from here ------ # OLD_SI: 'FG' # OLD_DI: 'JM' # OLD_SI !:p=\71\70 # OLD_DI !:q=\77\74 # NEW_SI !:x=\71\68 # NEW_DI !:y=\77\74 -------------- until here SICE2NEW.MS cut from here ------ !binary !include sice-val.ms # mov si,OLD_SI -> mov si,NEW_SI \190:p \190:x # mov di,OLD_DI -> mov di,NEW_DI \191:q \191:y # cmp si,OLD_SI -> cmp si,NEW_SI \129\254:p \129\254:x # cmp di,OLD_DI -> cmp di,NEW_DI \129\255:q \129\255:y # cmp w,[bp+4],OLD_SI -> cmp w,[bp+4],NEW_SI \129\126\4:p \129\126\4:x # cmp w,[bp+0],OLD_DI -> cmp w,[bp+0],NEW_DI \129\126\0:q \129\126\0:y # mov w,[bp+4],OLD_SI -> mov w,[bp+4],NEW_SI \199\70\4:p \199\70\4:x # mov w,[bp+0],OLD_DI -> mov w,[bp+0],NEW_DI \199\70\0:q \199\70\0:y # not sure about these ones... # cmp w,[4],OLD_SI -> cmp w,[4],NEW_SI \129\62\4\0:p \129\62\4\0:x # mov ax,OLD_SI -> mov ax,NEW_SI \184:p \184:x ------------ until here